Many computer networks employ Dynamic Host Configuration Protocol (DHCP) to enable a server to automatically assign Internet Protocol (IP) addresses to individual computers in a particular network from a defined address range or address scope that has been configured in the network. More specifically, a particular host or DHCP client device may request an IP address from the DHCP server, which may then provide IP configuration information to the requesting host in order to enable the host to communicate locally within the network and with other hosts that may be located in remote or external networks. For example, the IP configuration information provided to the requesting host may generally include a unique IP address assigned to the host, an IP lease period that defines how long the assigned IP address will be valid, and various other IP configuration parameters (e.g., a subnet mask, default gateway, etc.).
In general, any particular network may deploy one DHCP server in a standalone configuration or multiple DHCP servers in a redundant configuration to service IP address requests and manage IP configurations in the network. Furthermore, in a typical network that employs the DHCP standard, DHCP client devices connect to the DHCP server via one or more network elements, wherein a particular network element (NE) may include a router, switch, hub, or other suitable equipment that provide transport and switching services to enable the DHCP client devices to communicate with other computers on the local network and/or remote or external networks. Accordingly, because each DHCP client device can only receive IP configuration information while connectivity exists with the DHCP server, various problems may arise when one or more DHCP servers fail or otherwise lose connectivity to the network elements that connect the DHCP clients to the DHCP server. However, mechanisms that are typically used to recover from DHCP server failure tend to suffer from various drawbacks and limitations in relation to suitably addressing the problems that may arise when a DHCP server fails or otherwise loses connectivity.
More particularly, FIG. 1 illustrates a network architecture 100 typically used to provide DHCP server recovery, wherein during normal conditions various DHCP client devices located on an internal data network 140 may request IP addresses and receive IP configuration information from a DHCP server 110 via one or more network elements 120a-120c disposed in a communication path between the internal data network 140 and the DHCP server 110 in order to access an IP network 150 (e.g., the Internet). In response to the DHCP server 110 failing or otherwise losing connectivity, standard techniques to recover the DHCP server 110 generally depend on availability and integrity associated with a backup source that maintains IP configuration information that the DHCP server 110 has provided to any DHCP client devices located on the internal data network 140 and any network elements 120a-120c that connect the DHCP client devices to the DHCP server 110. For example, if the DHCP server 110 fails in a redundant deployment, recovery may depend on a redundant DHCP server 115 maintaining the backup source that provides the IP configuration information necessary to recover the DHCP server 110 that failed. However, developing an appropriate DHCP database backup solution to minimize the window in which the backed up database has inaccurate data may require different and often complicated DHCP database backup recovery strategies because any particular customer network may have different or unique characteristics. Additionally, any DHCP database backups must be performed in a timely manner to ensure the most accurate snapshot possible, which can be a substantial burden because frequent DHCP database backups may be necessary.
Furthermore, in a standalone deployment, the architecture 100 would not include the redundant DHCP server 115, meaning that customer intervention would be required to recover from failure associated with the standalone DHCP server 110. For example, in a standalone deployment, the customer that owns the internal data network 140 would be required to maintain a network element management station (EMS) 130 that periodically backs up the IP configuration information from the DHCP server 110 to a DHCP backup database 135, which tends to be a manual and cumbersome process, especially in networks that have many client devices and network elements 120a-120c (e.g., because the DHCP backup database 135 may require substantial storage resources, and even when the typical amount of DHCP data backed up is relatively small, the customer must still have and maintain a reliable mechanism to perform timely DHCP database backups). Furthermore, suitably recovering the DHCP server 110 relies heavily on frequent and timely backups to avoid stale DHCP data, which becomes more likely with network growth and configuration changes, and having the DHCP backup database 135 on the internal data network 140 requires the customer to restore the DHCP server 110 in a timely fashion, which tends to burden customers that desire “plug and play” network operations, administration, and management (OAM) deployment models. For example, as noted above, DHCP backup solutions tend to require complicated recovery strategies and raise substantial management burdens to minimize the window in which the DHCP database backup has stale or otherwise inaccurate data (e.g., frequent DHCP database backups, possibly every few minutes, would be needed during an automatic network discovery phase in which many hosts may be seeking DHCP configurations in a short time period, while subsequent DHCP server recovery needs to happen quickly to ensure that existing configured hosts retain DHCP configured information, for example over lease expiry, and to allow new hosts to receive DHCP configurations as soon as possible).
Another mechanism that may be used to recover from DHCP server failure may involve planning and provisioning static IP addresses (i.e., one IP address persistently assigned to each host), whereby a DHCP server 110 that has failed may simply retrieve the static IP configuration information upon coming back online. However, planning and provisioning static IP configurations in the DHCP server 110 may defeat customers' needs to have a “plug and play” network OAM deployment. For example, to manage an IP-based optical network (e.g., IP network 150), the EMS 130 or another suitable operations support system (OSS) typically associates each network element 120a-120c with a specific IP address and DHCP assigned IP configuration that must be retained for the entire duration that each network element 120a-120c may be deployed. Furthermore, if a customer that owns and operates the internal data network 140 according to an OAM deployment model that involves manually provisioning all IP communications data subsequently chooses to upgrade the network 140 to a “plug and play” network OAM deployment model, the DHCP server 110 would have to discover and configure each network element 120a-120c and DHCP client device, which may consume substantial time and resources.
Accordingly, because existing techniques to recover from DHCP server failure tend to suffer from various drawbacks and limitations, improved techniques to provide DHCP server recovery are desirable.